1. Field of the Invention
The present invention relates generally to computer software and computer network applications. More specifically, it relates to journalling and recovery mechansims for configuration databases in computer networks.
2. Discussion of Related Art
One type of conventional computer network involves connecting a series of personal computers referred to as clients (e.g., Sun SPARC workstations or IBM PCs), to one or more server computers. The client computers are generally self-sufficient and contain within their own memory much of the information needed to run user applications and perform network operations. That is, they contain information regarding their own configuration with regard to both software and hardware capabilities and requirements. The client computers typically access the network servers for a variety of reasons such as, for example, accessing network software applications, sending and receiving email, retrieving and storing information on a network database. However, information specific to a particular client computer generally resides on the client computer. This information can include, for example, the amount of memory or databus types, hardware specifications, such as what type of databus or additional processors. Since the client computers are relatively self-sufficient and store their own configuration information (and, thus is not available on the server computer), the task of data and application management on a client computer has become increasingly burdensome.
In the conventional network configuration, the process of installing new software or new applications is a static process. In such a configuration, the configuration information for each PC is defined on each client machine. Thus, the network administrator must statically define each configuration on each PC. In a conventional computer network configuration, configuration information for each particular sub-system or client is hardcoded in the particular client. Furthermore, with conventional network configurations using self-sufficient clients connected to network servers, application maintenance such as installing new versions or major upgrades to software, where the upgrade requires knowledge or access to a subsystem's configuration, normally requires that the application or the network be "brought down" to do the maintenance.
With conventional computer networks that have multiple clients and a server in which the server contains information that is needed by a client for various reasons, in many cases all the data on the server needed by or relevant to the client is moved from the server to the client. This can typically involve moving large amounts of data, much of which may not be used or is not necessary for the client to operate. Transferring all the data to the client is inefficient and increases network traffic. In addition, the client must have sufficient memory and storage to store all information relating to that particular client from the server. For example, devices such as PDAs and smart cards which do not have large amounts of storage cannot contain in its own memory all information including configuration information that might be relevant to that particular device.
Present methods of journalling or tracking updates, modifications, or inserts (i.e. transactions) made to configuration databases lack certain key features required in high-volume, real-world networks and that are expected in practical day-to-day operations. Generally, configuration databases do not have adequate recovery mechanisms to recover transactions or operations made to the database, and related data, in the event of a "crash" or other catastrophic failure. The data stored in a configuration database is typically sensitive data that must be recoverable in the event of a failure, whether of a single transaction or of the entire database. Journalling mechanisms of present configuration databases typically do not have the granularity or robustness that would allow a system or network administrator to examine a journal to see, for example, which operation by an end-user corrupted or damaged the configuration database. In addition, most journalling mechanisms for configuration databases are tailored for a specific type of memory or persistent storage medium, such as a specific relational database, a particular directory service, or other specific storage mechanism. This limits the portability and flexibility of the configuration database and the journalling mechansim.
Recently, fully functional and reliable journalling mechanisms have become necessary since computer networks have been growing in terms of types of computers and functionality, and particularly in terms of number of users, which in some networks has been increasing exponentially. Thus, recent configuration databases contain large amounts of data. In addition, the information contained in configuration databases has been growing more complex with time and is also updated more frequently than was done in earlier configuration databases which were significantly more static in nature. In addition, most journalling mechanisms associated with databases have the function of returning the database to a consistent state, which is adequate for certain purposes but may not for those where all the data must be recovered to ensure high availability of the clients, such as network computers.
Therefore, it would be desirable to have a journalling mechanism for a configuration database that maintains a detailed journal of all updates and modifications made to the database. It would also be desirable to have a journalling mechanism that contains actual data relating to the updates and modifications to allow a full reconstruction of the configuration database in the event of a failure. It would also be desirable to have a generic journalling mechanism in that it can function independent of the type of persistent storage being used to store the configuration database.